cache: includes cpu features in cache keys #2220
Conversation
there's a discussion about "offline" compilation, and if that happens, the CPU feature incompatibility becomes the problem. This hardens the cache against it by including the cpu id in the file cache keys so that the content will be used exactly on the same CPUs. Note that this impacts only amd64 target. Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
|
thanks guys! |
|
I'm a bit ambivalent about this one. OTOH, this avoids crashing with is Good™. OTOH this may actually make it harder to support “offline” caching. For offline caching, which I don't know if we want to support, IMO the best approach would be a flag that tells the compiler not to use any features above the Go baseline (i.e. assume no CPU flags) and then you can safely Go embed the compiled thing, if you favor startup speed over huge binaries. Including CPU flags in the cache key might make it harder to do that. So I guess the usefulness of this, as is, is whether people are OK with configuring a file cache, then filling it up in CI, and then distributing the thing with (IKD?) Docker or something. It's not my world, so I have no idea if this is what people are looking for. That said, this is done, and works, and is safer, and doesn't break anything, so I'm good. Pick your battles and stuff. 👍 |
|
@ncruces Thanks for mentioning the Go baseline - had the random thought that perhaps we shouldn't do any cupid detection. Since Go has Anyways, I don't think it's an important, or even great, enhancement to implement, but maybe an idea for where there is a will and a want. |
there's a discussion about "offline" compilation, and if that happens,
the CPU feature incompatibility becomes the problem.
This hardens the cache against it by including the cpu id in the file cache keys
so that the content will be used exactly on the same CPUs.
Note that this impacts only amd64 target.